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Intellectual Property Rights 

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http ://webapp . etsi .org/IPR/home . asp ) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Satellite Earth Stations and 
Systems (SES). 



Introduction 

Terrestrial Internet protocols, in particular for signalling, management and control, are often ill adapted to the specifics 
of satellite networks (TR 101 984). It has been the goal of the BSM work to investigate which protocols should be 
adapted to the BSM world and propose a number of specific technical specifications to achieve this goal. In order to 
link all those documents under a common framework, the present document defines a BSM functional architecture. The 
architecture is not satellite system specific and relies on client server architectures to perform the needed tasks without 
interference with IP protocol operations. 



ETSI 



5 



ETSI TS 102 292 V1 .1 .1 (2004-02) 



1 Scope 

The present document presents the architecture that relates the work done in SES BSM TRs on standardization (see 
TR 101 984 and TR 101 985, Addressing and Routing (see TR 102 155), Multicasting (see TR 102 156) and 
Performance and QoS (see TR 102 157). The present document provides the introduction to the subsequent Technical 
Specifications (TSs). The focus of the BSM work is on IP version 4 (IPv4). Actual protocol specification is beyond the 
scope of the present document and will be issued in specific TSs. 



2 Void 



3 Definitions and abbreviations 
3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

adaptation: process of adapting standard protocols for better performance over a satellite (or other) subnetwork 
architecture: abstract representation of a communications system 
function: any discrete element that forms a defined part of an architecture 
scenario: predicted sequence of events 



3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

3GPP Third Generation Partnership Project 

ATM Asynchronous Transfer Mode 

BGP Border Gateway Protocol 

BSM Broadband Satellite Multimedia 

CSF Client Server Function 

HTTP Hyper Text Transfer Protocol 

IETF Internet Engineering Task Force 

IGMP Internet Group Management Protocol 

IP Internet Protocol 

IPv4/v6 Internet Protocol version 4/6 

MPLS Multiprotocol Label Switching 

NAT Network Address Translation 

PEP Performance Enhancing Proxy 

PIM Protocol Independent Multicast 

QID Queuing IDentifier 

QoS Quality of Service 

SD Satellite Dependent 

SI Satellite Independent 

SI-C-SAP Satellite Independent - Control plane - Service Access Point 

SI-M-SAP Satellite Independent - Management plane - Service Access Point 

SI-SAP Satellite Independent - Service Access Point 

SI-U-SAP Satellite Independent - User plane - Service Access Point 

SLC Satellite Link Control 

SMAC Satellite Medium Access Control 

SPHY Satellite PHYsical 

ST Satellite Terminal 
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USB Universal Serial Bus 

WG Working Group 



4 Architectural framework 

4.1 Principles 

The BSM architectural framework is based on the principle that the recommended Technical Specifications should be 
linked by a common thread. Obviously all BSM protocols can be classified in the OSI layered model: the protocols the 
BSM uses to transport IP traffic mostly belong to the layers 2, 3 and above as they deal with MAC layer adaptation to 
support IP services and address resolution, network protocols such as routing, and finally policy control and 
management protocols for quality of service and resource management TR 101 985. It has been a recommendation of 
the IP interworking over satellite TR 102 155, TR 102 156 and TR 102 157 that the "adaptation" of the IP protocol at 
the ingress and egress of the BSM be located in a "Protocol Manager". This entity is mainly a control path entity that 
intercepts the appropriate IP protocols and ensures that they are correctly supported over the BSM. 

In the BSM protocol stack, the "manager" resides mostly above the SAP. Its major functions include: 

• How IP protocols and packet markings are to be interpreted and transmitted through the BSM. 

• Which Satellite Independent (SI) protocols are used. 

• And how they in turn trigger the Satellite Dependent (SD) functions. 

4.2 Basic concepts 

In addition to the definitions provided in clause 3.1 some concepts that are basic the BSM architecture are further 
explained below: 

• Adaptation: as defined in clause 3.1 adaptation refers to the process of adapting standard protocols for better 
performance over, in the present document, a BSM satellite subnetwork. Adaptation, which should be 
transparent to the general Internet, involves, for example, changing timers, filtering traffic and reducing the 
transmission of messages over the satellite link to the protocol servers. 

• Architecture: the architecture is an abstract representation of a communications system. Three 
complementary types of architecture are defined: 

Protocol architecture: the protocol stacks involved in the operation of the system and the associated 
peering relationships. 

Functional architecture: the discrete functional elements of the system and the associated logical 
interfaces. 

Network architecture: the discrete physical (network) elements of the system and the associated 
physical interfaces. 

• Scenario: in the present document a scenario will describe a realistic worked example, showing how a defined 
set of functions operate and apply to a specific IP interworking situation (or situations). Scenarios demonstrate 
both "why" we need a given set of functional specifications and "how" the proposed functional decomposition 
works to provide the desired result. In general, a scenario will be described by reference to one or more 
architectures. 
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Function: a function converts a set of inputs into a set of outputs. A function is formally defined by the sets of 
inputs and of outputs. The set of inputs can be a continuum (e.g. an analog signal) or discrete (e.g. a digital 
signal). It might be that some inputs produce no ouput e.g. silent discard in address resolution. Inputs and 
outputs can be assembled in blocks or vectors (datagrams, packets, frames, etc.). This is the most basic 
definition and it proves to be sufficient in some cases (black box diagram). At the opposite, a function is 
ultimately defined when it is possible to derive an output from any input. Between these two ends, all 
intermediate definitions are possible. In the BSM, a function can use any combination of the following: 

a protocol element (e.g. a complete stack or an single protocol entity); 

a logical element (e.g. a process or procedure); and 

a physical element (e.g. a router or server). 

Network engineering: 

1) In telephony , the discipline concerned with determining internetworking service requirements for 
switched networks, and developing and implementing hardware and software to meet them. In addition, 
network engineering includes the end-to-end provisioning of network resources to meet service needs. 

2) In computer science , the discipline of hardware and software engineering to accomplish the design 
goals of a computer network . 

3) In radio communications , the discipline concerned with developing network topologies. Because the 
BSM is concerned with all three functions all of those definitions apply. 

Traffic engineering: the determination of the numbers and kinds of circuits and quantities of related 
terminating and switching equipment required to meet anticipated traffic loads throughout a communications 
system . Traffic engineering also targets the reduction and suitable distribution of loads across the network. 



5 Overview 

Figure 1 presents the BSM protocol stack for unicast services and figure 2 the same stack with the added multicast 
protocols. An important feature of both figures is the Satellite InDependent Service Access Point interface or SI-SAP 
interface. This interface provides the BSM with a layer of abstraction for the lower layer functions and makes use of a 
BSM specific identifier, the BSM_ID, to address BSM points of attachment. It allows the BSM protocols developed in 
the Satellite InDependent layer to perform over any BSM family. Moreover, the SI-SAP also enables the use of 
standard Internet protocols for example address resolution or multicast group management, directly over the BSM or 
with minimal adaptation to BSM physical characteristics. Finally the SI-SAP even makes it possible to envisage 
switching from one satellite system to another and to even a non-satellite technology while preserving the BSM 
operator's investment in layer 3 software development. 

Figure 1 shows that there are only a small number of generic functions that need to cross the SI-SAP and those are 
related to connection/session management, resource management or security. As seen in figures 1 and 2, the BSM 
protocols are based on the OSI layered protocol stack. For the IP services most of the work has concentrated on the 
network layers with links to the underlying data link and MAC layers. The reason for this is simple: the developed 
protocols for IP over BSM should primarily be located in the satellite independent part of the BSM stack to be 
applicable to a range of different satellite dependent lower layers such as for example, DVB-S and DVB-RCS. 
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Figure 1 : BSM protocol stack for unicast services 
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Figure 2: BSM protocol stack for multicast services 

The major identified requirements for the BSM specific protocols at the satellite independent layer (above the SI-SAP) 
are: 

• No BSM protocol should bring any changes to Internet protocols. 

• And when specific BSM functions are required they should be done via proxies or managers. 

As mentioned in clause 4, the recommendations the IP over BSM Technical Reports (see TR 102 155, TR 102 156 and 
TR 102 157) have proposed a number of specifications that are essential for the BSM to adequately handle current and 
future IP traffic. The specifications under development are identified within the OSI stack in figures 1 and 2. They 
cover advances in multicast, address resolution and routing/forwarding as well as resource management. The 
relationship between these functions is highlighted in clause 6. 
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6 SI-SAP architecture 

The SI-SAP (Service - Access Point) provides an abstract interface allowing BSM protocols to be truly System 
Independent (SI) and to apply to all BSM families. The SI-SAP is the interface at which services from the lower layers 
are translated into system independent semantics. 

For traffic handling the SI-SAP uses a BSM Identifier (BSM_ID) and a Queuing Identifier (QID): 

• The BSM_ID uniquely identifies a BSM network point of attachment and allows IP layer address resolution 
protocols (equivalent to ARP for IPv4 and ND for IPv6) to be used over the BSM. The details of the BSM_ID 
in term of format and its usage will be specified in the TS on Address Resolution. 

• The QID enables the BSM data transfer (IP packets) to be queued, policed and transmitted properly across the 
BSM. 

The traffic classes are central to the concept of the Queue ID (QID). Traffic classes available at the SI-SAP enable QoS, 
performance management and resource allocation. They are defined in details in TS 102 295. The BSM queues can be 
defined by QoS specific parameters (flowspecs, path labels or Diffserv markings) and associated to lower layer transfer 
capabilities (e.g. to different capacity request categories in the DVB-RCS model). Some QID could be assigned 
permanently and others being dynamically created to satisfy as certain QoS. The QID however not limited to a capacity 
allocation class; it relates also to flow/behaviour with defined properties. This includes: 

• buffer allocations for queueing; 

• buffer management policies (e.g. RED / drop tail); 

• priority in terms of transmission; 

• capacity allocation class (as mentioned in the previous paragraph); and 

• PID/channel ID mapping for segmentation/reassembly. 

All of the BSM services such data transfer, address management, group advertisement etc. use SI-SAP primitives; these 
primitives are used to define the exchanged information between the satellite independent upper layers and the satellite 
dependent lower layers via the SI-SAP. The primitives are classified into functional groups within the User plane (U), 
Control plane (C) and Management plane (M). Figure 3 presents a detailed overview of the SI-SAP data transfer 
functions. 
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Figure 3: SI-SAP detailed overview 



7 Network architecture 
7.1 BSM network architecture 

This clause reviews the major network architectures used for BSM networking. It also identifies the major interfaces 
that the BSM functional architecture will use. The network architectures are essential to define the specific client-server 
functions that will enable IP services over the BSM. For each of the recommended specifications (TS) a specific 
"manager" located in the appropriate server (in the appropriate domain) will be defined in relation with the appropriate 
BSM network configuration. Hence, the client server architecture relates to the specific network architectures and BSM 
hardware in the following way: 

• protocol clients are located in all STs and in Gateways when appropriate; protocol clients should not be 
located in attached networks; 

• protocol servers are located/distributed in the network or even across a network and are not strictly associated 
with gateways but with operators control and management networks; STs and/or Gateways communicate with 
the servers that are managed by its operator; 
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• all STs can be connected to multiple local hosts and can act as gateways to another subnetwork; and 

• in any of the defined configurations an OBP payload can be involved on the control path especially as regards 
resource management. 

The BSM network architectures are: 

• Access Network (star configuration) using transparent or processing satellite system (see figure 4); in this 
configuration the Internet is accessible in one hop via a gateway. While a processing payload could be 
involved in the control path it is not a requisite. Figure 5 illustrates the protocol stack for the star network and 
a transparent payload. 
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Figure 4: Star configuration access network 
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Figure 5: Star configuration example of a protocol stack 

Mesh Network using peer to peer communications between terminals/gateways (see figure 6). When the peer 
to peer connectivity is provided in one hop (ST to ST), this configuration uses an onboard processing device. 
This is the configuration most often associated with bridging or switching scenarios (see figure 7). The meshed 
configuration can also be supported over a transparent payload with double hop: data goes from the source ST 
to a Gateway and from the Gateway to the destination ST. A special case of the meshed scenario is when the 
BSM is used for interdomain connectivity, a likely scenario for both multicasting and bridging. 
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Figure 6: Meshed configuration 
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Figure 7: Meshed configuration: example of a protocol stack 
with Layer 2 switching in the satellite 



7.2 



BSM network interfaces 



Figure 8 presents the major interfaces to the BSM. The architecture described in the present document as well as the 
TSs that will define specific BSM functionality and protocols that deal with interfaces 12, 13 and 14 on the ingress 
(access) side and 17, 18, 19 and 110 on the egress (gateway) side. Table 1 details all the named interfaces. 
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Figure 8: Reference model of BSM access from TR 101 984 
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Table 1 : Interfaces for BSM access 



Ref. 


Interface name 


Description of interface 


Associated IP Interworking 
Architecture Role 


1.1 


External Network 
Interface 


Interface between end system 
and customer premises network 


Defines the QoS requirements 


I.2 


BSM Network 
Interface 


External interface between 
satellite access function and 
customer premises network 


Defines the QoS and framing requirements 


I.3 


BSM subnetwork 
service access 
point 


Internal interface 


May define the framing requirements 


1. 4 


BSM Satellite 
Independent 
Service Access 
Point (SI-SAP) 


Internal interface 


Main interface for IP interworking; 
abstracts the SD functions to the higher 
layers; interprets the QoS and framing 
requirements 


I.5 


BSM Access 
Terminal Air 
Interface (see note) 


Internal air interface 


Not at layer 3 


I.6 


BSM Gateway Air 
Interface (see note) 


Internal air interface 


Not at layer 3 


I.7 


BSM Gateway 
Satellite 
Independent 
Service Access 
Point (SI-SAP) 


Internal interface 


Main interface for IP interworking; 
abstracts the SD functions to the higher 
layers; interprets the QoS and framing 
requirements 


I.8 


BSM gateway 
subnetwork service 
access point 


Internal interface 


May define the framing requirements 


I.9 


BSM gateway 
adaptation service 
access point 


Internal interface 


Defines the QoS and framing requirements 


1.10 


BSM Gateway 
Interface 


External interface between 
satellite gateway function and 
terrestrial network 


Defines the QoS requirements 


1.102 


Alternative return 
channel Interface 


External interface to return 
channel (may be bi-directional) 


Defines the QoS and framing requirements 


1.110 


Alternative return 
channel gateway 
Interface 


External interface for return 
channel (may be bi-directional) 


Defines the QoS and framing requirements 


NOTE: The Access Terminal air interface may be identical to the Gateway air interface. 



8 Logical architecture 
8.1 Client server networking 

The client/server software architecture is a versatile, message-based and modular infrastructure that is intended to 
improve usability, flexibility, interoperability, and scalability as compared to centralized management. 

A client is defined as a requester of services and a server is defined as the provider of services. One widely used client 
server model is the Hyper Text Transfer Protocol (HTTP) at the basis of the transactions in the World Wide Web. 
HTTP uses "get" and "push" commands to request entities and provide responses. In the BSM, the client requests IP 
services from the BSM and the BSM server provides the adaptation protocols and other services to fulfil the request. 
The details of these transactions are beyond the scope of this note. A single ST can support both client and server 
software or provide the transit link to a server depending on the software, the targeted protocol and BSM network 
configuration. 
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8.2 Decomposition 

The BSM functionality can be separated into 3 logical segments (see figure 9) that follows the BSM stack and will 
clarify the functional architecture: 

• The User Services Segment is where the users services enter the BSM; its management functions are mostly 
real time and relate to packet handling and some packet level control; the applications located in the User 
Service Segment supply QoS requirements, Internet addressing and routing to the other segments; the User 
Services Segment in mainly located in the user (data) plane. 

• The Communication Segment provides the connectivity between BSM segments and the Internet; while the 
communication segment is not intrinsically linked to any management function it can (especially in the case of 
processing satellites) provide support to resource management functions. 

• The Communication Services Segment is where the specific non real time BSM services are provided and 
constitutes the main focus of the Technical Specifications; it contains all the servers that will enable 
communication to and from the BSM and the Internet; this is where the BSM protocols are adapted to the 
outside world. The communication services segment is mainly located in the control plane with some functions 
being in the Management Plane. In figure 9, the Communication Service Segment is illustrated as potentially 
being hosted by a number of providers. 




User Plane/Data Path 

Control/Management Plane/ 
Control Path 

Figure 9: Logical decomposition 

As mentioned in the previous clause a client - server architecture where servers are distributed amongst the operating 
entities (satellite, network and internet service providers) and the clients are located in terminals and gateways is 
favoured for its scalability, flexibility and ease of use with existing management and control systems. 
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8.3 Logical interfaces 



For the client-server model that we are adopting, a generic interface called Client Server Function (CSF) interface is 
defined and then a series of subdivisions of this interface - one for each TS functions can be introduced, namely: 

CSF-1: The interface between the IETF protocols and the Client [interworking] function (internal to the IP 

layer) this is similar to the interfaces 1.3/ 1.8 (see figures 8 and 10). 

CSF-2: The interface between the peer IETF Client [interworking] functions (shown as user plane data 

path in figure 10); 

CSF-3: The interface between the Client function and the Server function(s) (shown as control plane path 

in figure 10). 



End 
System 



User services segment 
CSF-1 



USB 
Or 
Ethernet 



SD 
(family 



CSF-2 



User services segment 
CSF-1 



SD 
(family) 



Communication Segment 



CSF-3 



SD 
(family) 



SI 



IP 



SD 
family) 




USB 
Or 
Ethernet 



CSF-3 



Communications 
Services Segment 




Figure 10: Protocol interfaces 
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9 Scenarios 
9.1 Summary 

This clause describes how a packet transits in the BSM and highlights how the TRs and proposed TSs interact in order 
to provide the BSM IP services. The BSM can act at Layer 2 on an Ethernet, at Layer 3 on a routed network and 
Layer 4, doing UDP or TCP port mapping and/or Network Address Translation (NAT). The BSM can also act above 
layer 4 by including a Performance Enhancing Proxy (PEP) or a transport relay functionality, or including an 
application layer proxy like a Web cache. This is all included in the concept of the "protocol" manager. For each of 
these functions the processing of a packet will change slightly but the "life" of a packet in the BSM follows the 
following steps: 

• the protocol data unit is extracted at the ingress to the BSM from the ingress network interface; 

• address processing (verification, resolution) is performed and the address of the egress BSM ST (and port on 
the ST) is found; in the case of multicasting there can be multiple egress STs, addresses can point to content 
not STs and group management will be necessary; 

• other header processing is performed including QoS to priority mapping and queuing rules; 

• the IP packet is segmented into SDU(s) (when appropriate); and 

• the SDU is forwarded based on routing rules or network engineered paths. 

A summary of the services offered by the BSM and how packets are processed is available in table 2. 



Table 2: Summary of BSM packet processing 



Packet Encapsulation 


Services 


Summary 


IP 




IP-layer address lookup is performed. 

Any-to-any connectivity is supported over the BSM among a closed 
group of logical ports. 


IP over AAL5/ATM 


BGP/MPLS VPNs 


The IP Packet is extracted and IP-layer address lookup is performed. 
Any-to-any connectivity is supported over the BSM among a closed 
group of logical ports. 

From the standpoint of the user network, the BSM is a standard BGP- 
capable router. 


IP over MPLS 




The IP over MPLS Packet is extracted. 

Point-to-point connectivity is supported over MPLS between logical 

ports at the two ends of the BSM. 

Same applies to Ethernet and ATM over MPLS. 


IP over DVB 




Could be a transparent function; if not the IP packet is extracted. 
IP packet is encapsulated by MPE over a DVB transport stream; the 
MPE encapsulation could be part of the SI convergence protocols. 


Ethernet 


VLAN 


The IP packet is extracted. 

Ethernet framing information could be used (out of scope). 
Point-to-point connectivity is supported over logical ports at the two 
ends of the BSM. 



9.2 Network engineering functions 

In order for the packet to be processed efficiently and forwarded effectively to its destination, a number of preliminary 
operations must have had taken place in advance. While network engineering (as a end to end function) is beyond the 
scope of the relevant TS it is important to highlight its essential functions as they relate to BSM packet transfer 
properties. Table 3 presents how the BSM protocols provide the network engineering services necessary for IP packet 
transfer over the BSM. 
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Table 3: BSM protocols and network engineering 



BSM Technical Specification 


User plane processing 


IGMP/PIM 


The definition of IGMP/PIM adaptation, proxies and 
snooping for gateways and terminals in order to 
manage how multicast packets will be forwarded in 
the BSM and how multicast services will be 
managed. 


Multicast Address Resolution 


Address Resolution to provide the services to map 
BSM multicast addresses to IP addresses. 


Multicast Session Control (QoS) 


Defines how multicast packets in the IP layer will be 
handled in the BSM. 


BSM Address Resolution 


Address Resolution to provide the services to map 
BSM unicast addresses to IP addresses. 


BSM Routing 


BSM Routing services to compute and distribute 
routing information. 


RVSP/MPLS Framework 


RVSP/MPLS framework that discovers paths, 
defines flow mapping information and path access 
rules and reserves resources. 


Diffserv Framework 


Ensure that the BSM and its attached networks 
agree on how to process Diffserv marked packets 
including the definition of traffic classes and 
performance goals (and Service Level 
Agreements). 


Security 


Ensure that the BSM ensure link security and 
content protection while integrating in the end to 
end security architectures of the Internet. 



The "preliminary" operations ensure that the packets are well formed, that the BSM is ready to process packets, that the 
right settings have been made, that the right information exist about specific operators, that the BSM resources are 
available and have been reserved, that RSVP or MPLS paths have been established and verified, etc. They form the 
essential of the "Communication Management Services". 

Traffic engineering can be associated to different categories, mostly non real-time such as: 

• Information framing standards to create the packet and address resolution services. 

• Initialization that ensures the availability of the BSM. 

• Network management functions and subscriber specifics that set service agreements between operators and 
their customers; these are the parameters that allow packets to be forwarded according to macro-level service 
rules and generate the revenues of the service provider. 

• Traffic engineering that sets up paths and rules to access them and enable the traffic to be effectively 
transmitted from ingress to egress. 

As can be seen in table 3 the proposed TSs allow the full engineering of an IP services within the BSM. 

9.3 Packet processing 

A packet entering the BSM can be: 

• an IPv4/v6 packet; 

• an MPLS packet; 

• ar an Ethernet frame or other layer 2 frame (or ATM cell). 

The SI has all the functions necessary to adapt and de-encapsulate (and re-encapsulate) the incoming and outgoing 
packets to their appropriate protocols and interfaces. It also ensures that the packets are authorized to be transported 
over the BSM. 
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The flow of the IP packet will follow a well defined suite of functions as will be described in clauses 9.3.1 and 9.3.2. In 
this example, the processing onboard is excluded. In the case of an Ethernet frame the processing would be slightly 
different but the main steps would remain the same. 

9.3.1 Ingress processing 

The ingress processing, how the packet is treated when it enters the BSM, can be summarized a follows: 

• verify the ingress IP header is valid (reverse address lookup) to avoid denial of service attacks; 

• determine if the packet is MPLS; if so process as a MPLS marked packet and forward on the pre-determined 
path; 

• determine from the IP address (if possible; if IPSEC is used this step is not possible) if this is: 

a unicast traffic packet; 

a multicast packet; 

a signalling/maintenance packet. 

• find the egress BSM address from the ingress IP address; if no address resolution has been performed either 
perform address resolution or forward to the default gateway; 

• ensure connectivity is established through the BSM; 

• authenticate the packet if necessary; 

• find the BSM priority/traffic class from the DSCP markings or from the destination; if not marked and not a 
signalling packet mark as best effort; 

• create the BSM header and pre-pend the header before or after packet segmentation into BSM data units 
(encapsulation); and 

• send the segmented traffic to the appropriate queue to await bandwidth on demand, scheduling and 
transmission over the BSM. 

9.3.2 Egress processing 

At the egress (the exit of the BSM), the processing is reversed: 

• verify the received BSM header is valid (reverse address lookup) to avoid rogue terminal transmissions; 

• determine if the packet is MPLS; if so process as a MPLS marked packet and forward on the pre-determined 
path; 

• determine from the BSM address if this is: 

a unicast traffic packet; 

a multicast packet; 

a signalling/maintenance packet. 

• find the egress IP address from the egress BSM address; if no address resolution has been performed either 
perform address resolution; 

• re-assemble the IP packet and packet header from the BSM; and 

• send the IP packet to the appropriate queue to await routing to the destination address and port. 
Table 4 illustrates how the BSM protocols allow the full processing of an IP packet within the BSM. 
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Table 4: BSM protocols and packet processing 



Technical Specification 


User plane processing 


IGMP/PIM 


Forward the BSM multicast packets with the 
appropriate rules. 


— — ; 

Multicast Address Resolution 


Maps IP multicast addresses to BSM destinations. 


Multicast Session control (QoS) 


To ensure that multicast packets are processed 
doouiuiiig lu iiic riyiu ruico iribiuc nic doivi. 


BSM Address resolution 


Maps IP addresses of ingress packets to a BSM 
destination. 


BSM Routing Tables 


Define the forwarding rules of the IP packets. 


RVSP/MPLS framework 


Recognizes which packet is part of which flow/path 
and forwards it accordingly. 


Diffserv framework 


Mapping Diffserv markings to BSM priorities. 


Security 


Ensure the BSM segment security (link and 
content). 
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